The problems and solutions addressed by the invention are described herein in terms of the Internet and the TCP/IP protocols that form the basis of Internet communications. However, the invention can apply to other communication protocols as well, depending on the specifics of the protocols.
Internet Network Address Translation is used for several reasons. The main reason is to economize on the use of public addresses. The Internet Protocol (IP) address of a Network Address Translator (NAT) is generally a public address. That is, the NAT IP address is known to the outside world, while all of the servers or clients behind the NAT are private addresses administered by the NAT and unknown to the outside world. In such a case, the outside world communicates with the NAT and the NAT controls the communications with the appropriate servers and clients behind it. This means that the IP addresses of devices behind the NAT only have to be unique within that family, but can be duplicative of other IP addresses in the rest of the world. The standards for Network Address Translation (NAT) are set forth in the Internet Engineering Task Force (IETF) RFC 3022, entitled “Traditional IP Network Address Translation”.
The original Internet was not designed with security as a primary factor. In fact, the Internet was purposely made relatively open as an aid to scientific and educational communication. However, the advent of the Web and its commercial uses has increased the need for secure Internet communications. The Internet Security Protocol, commonly known as IPsec, was defined to address these issues. For example, IPsec provides for the authentication of network users and/or for the encryption of transmitted data. An IPsec communication between source and destination addresses is administered in accordance with a security association (SA), which is one or more rules that define the IPsec processing that is applied to the communication. IPsec is defined in RFC 2401 and other RFCs.
There are inherent incompatibilities between network address or port translation and IPsec processing. These incompatibilities are a barrier to deployment of IPsec. RFC 3715 recognizes and discusses some of these incompatibilities, but offers no general solutions. Two patent applications assigned to IBM solves some of these incompatibilities relating to duplicate packet sources in an environment involving network address port translation (NAPT). The first, entitled “Negotiating IPsec Security Associations and Preventing Duplicate Sources in Networks that Involve Network Address Network Translation” is given Ser. No. 10/907,661. The second is an improvement to Ser. No. 10/907,661, and is given Ser. No. 10/907,659. The applications are incorporated by reference into this application in their entirety.
There are certain situations that occur during negotiations of IPsec security associations that require recognition of certain network topologies to avoid improper or erroneous results. For example, when a connection includes a network address translator (NAT), a host may need to reject a SA negotiation if a server is trying to initiate a tunnel mode SA that terminates in an intermediate router or security gateway. In such cases, an involved IP address can be private, meaning that it might be impossible for the host to route packets properly. Other situations involving network address port translation (NAPT) can result in a problem of duplicate IP sources. This means that it is possible to receive packets from different sources that contain identical source IP addresses. Solutions to the duplicate source problem are addressed in the patent application Ser. Nos. 10/907,661 and 10/907,659, identified above. It is also advantageous if, during SA negotiations, a server identifies situations in which the solutions of these patent applications can be applied.